昨天解完了資料庫裡那些摩斯密碼。

今天離開資料庫，一口氣跳回使用者真正會看到的第一眼：

這個網站，到底長什麼樣子？

BuJo 在開始寫任何一行前端程式之前，我們畫了一張圖。

畫的當下，我不知道它叫什麼。

只知道我們需要一張圖，把「這個網站有哪些頁面、從哪裡可以點到哪裡」講清楚，不然四個人各自寫各自的，最後一定接不起來。

後來我才發現兩件事。

第一，這張圖其實卡在兩種正式產出物中間，兩邊都沾到一點，但兩邊都不完全是。

第二，在這張圖跟「開始寫程式」之間，還有一整層我們當時完全不知道存在的東西。

畫面不是一步就長出來的

我原本以為，介面設計就是：

想一下畫面長怎樣，然後把它做出來。

後來我才知道，很多團隊會用不同層次的產出物，一步一步把模糊的想法變清楚。我把它整理成三層來看：

這個順序不是絕對規定，不同團隊、不同專案、不同時程，做法都可能不一樣。

但它有一個很好用的思考方式：

每一層都在替下一層設定邊界。

風格沒定，畫面層就很容易每一頁各自發揮。

結構沒定，做到一半才可能發現流程少了一步。

畫面直接做得很完整，大家又很容易開始討論顏色、圓角、陰影，而不是先問：

「這個頁面真的需要存在嗎？」

而且介面設計不只是在桌機寬度下看起來對，還要確認 RWD（Responsive Web Design，響應式網頁設計），也就是桌機、平板、手機等不同裝置下，資訊和操作要怎麼重排。

風格層：先講清楚這個產品要像什麼

Mood Board（情緒板）是很前面的一步。

做法其實不神祕，就是把喜歡的圖片、配色、字體、網站截圖、視覺方向蒐集起來，整理成一張板子。

它的價值不只是「看起來很漂亮」，而是把那些講不清楚的感覺，變成可以指著討論的東西。

一個人說「我想要溫暖一點」，另一個人腦中浮現的可能是米色木頭，也可能是橘紅色霓虹燈。

如果大家可以指著同一張圖說：

「我說的溫暖比較像這個，不是那個。」

誤會就會少很多。

接著，Mood Board 通常會再收斂成設計規範（Design System）。

設計規範可以包含主色、輔色、字級階層、間距、圓角、陰影、按鈕樣式、卡片樣式、表單狀態等等。

到這一步，「溫暖」「親切」「乾淨」這些形容詞，才會慢慢變成一組可以被執行的規則。

結構層：IA 跟 User Flow 差在哪

資訊架構（Information Architecture, IA）和使用者流程（User Flow）這兩個詞，我一開始其實也分不太清楚。

後來才抓到一個比較好懂的差別：

IA 管的是「東西放在哪」。

它描述這個產品裡有哪些內容、怎麼分類、誰在誰底下，產出比較像一張網站地圖。

例如一個網站裡有首頁、活動頁、好友頁、通知頁、個人設定頁，這些頁面彼此怎麼分層、從哪裡進去，這比較偏 IA 在處理的問題。

User Flow 管的是「使用者怎麼走」。

它會挑一個具體目標，從起點畫到終點。

例如「建立一個活動」這件事，使用者從哪個頁面開始？按了哪個按鈕？進到哪個表單？送出後去哪裡？

一個比較像名詞的組織，一個比較像動詞的順序。

而且 User Flow 很重要的一點，是它不只畫順順走完的那條路，也會處理分支和邏輯判斷。

沒填資料按下一步會怎樣？如果使用者不是活動建立者，會看到一樣的按鈕嗎？

這些分支如果沒有先攤開，通常不會有人在開發前想到，只會在測試的時候被撞到。

畫面層：Wireframe、Mockup、Prototype 差在哪

到了畫面層，還有一條很重要的軸線，叫保真度（Fidelity）。

保真度指的是：這份設計產出跟最後成品有多像。

由低到高，大概可以分成三階：

線框圖（Wireframe，低保真）
通常是灰階方框、假文字、沒有正式配色，也沒有真實圖片。

它主要回答：

東西放在哪？誰比較重要？資訊順序怎麼排？

Wireframe 的重點不是漂亮，而是刻意不要太漂亮。

因為它越簡單，大家越不會被顏色、圖片、陰影帶走，反而能專心討論結構本身。

如果是實際專案，Wireframe 也不一定只畫一個尺寸。

至少要確認 RWD 的基本方向：桌機、平板、手機上，資訊是怎麼重排的，主要操作會不會被藏得太深。

視覺稿（Mockup，高保真）
Mockup 會套上真正的顏色、字體、圖片和元件樣式，看起來已經很接近成品。

但它通常還是靜態的。

也就是說，你看得到畫面長什麼樣子，但不一定能真的點。

互動原型（Prototype）
Prototype 可以點，可以切換頁面，也可以模擬狀態變化。

它不一定有真正功能，底下也不一定接資料庫，但它可以讓團隊感覺：

使用者真的操作起來順不順。

我一開始覺得 Wireframe 很奇怪。

都有 AI 了，為什麼還要故意畫一個醜醜的灰色版本？

後來才懂，它醜是刻意的。

低保真的好處是便宜、快、容易丟掉。

一張灰色方框圖推翻重畫，可能是十幾分鐘的事。

但一個已經做到一半的互動原型要推翻，就會痛很多。

BuJo 是怎麼走完這三層的

回頭對照這三層，BuJo 的走法其實蠻有趣的。

我們不是完全沒有設計流程，而是每一層走得不太一樣。

風格層：我們先決定 BuJo 要給人的感覺

這個網站是做給誰用的？希望它給人什麼感覺？

因為 BuJo 是一個幫朋友約時間、安排活動的平台，所以我們不希望它看起來太商務、太冷冰冰。

它需要有一點生活感、親切感，也要讓使用者覺得：

「這不是一個壓力很大的工具，而是一個可以讓約朋友變簡單的地方。」

所以我們先根據目標客群和產品氣質，去蒐集喜歡的圖片、網站範例和視覺方向，整理成 mood board。

後來也把這些方向收斂成設計規範，讓顏色、字體、按鈕、整體氣質有一個可以對齊的基準。

結構層：我們畫了一張介於 IA 和 User Flow 之間的圖

結構層，我們做了一半。

我們根據 Day 2 的 Function Map，把功能一項一項對應成頁面，畫出開頭那張介於資訊架構（Information Architecture, IA）和使用者流程（User Flow）之間的圖。

那張圖用藍色代表頁面、黃色代表彈窗，線上標的是使用者的操作。

現在再看，它同時沾到兩邊。

它有 IA 的層級感，因為它在整理網站裡有哪些頁面，以及它們大概怎麼連在一起。

它也有 User Flow 的味道，因為它在描述使用者怎麼從一個畫面走到另一個畫面。

但它缺了 User Flow 很重要的一塊：判斷分支和例外情境。

所以它比較像一張畫面流程圖（Screen Flow）。

這個詞不像 IA 和 User Flow 那麼有統一標準，不同團隊可能會有不同叫法。

但它很適合形容 BuJo 當時那張圖：它把主要頁面和畫面之間的跳轉關係先畫出來，讓團隊有東西可以對齊。

畫面層：我們直接跳到可以點的 Prototype

畫面層，我們直接跳到 Prototype。

我們沒有先做 Wireframe，也沒有先做完整 Mockup。

而是把 Function Map、設計規範和那張畫面流程圖一起交給 Claude Code，請它產出第一版可以互動、但沒有真正功能的網站。

那個版本不能真的登入、建立活動或寫入資料庫，但它可以點，也可以看到頁面之間怎麼切換。

會這樣做，是因為 BuJo 不是市面上已經有固定範本的產品。

沒有一個現成畫面可以指著說：

「我們就做成像那個一樣。」

每個組員腦袋裡的 BuJo 都長得不太一樣，所以我們需要的不是只有文件，而是一個大家可以直接點點看的共同版本。

它讓我們可以比較具體地討論：

「我們想像的是不是同一個東西？」

以「對齊想像」這個目的來說，我到現在仍然覺得它有幫上忙。

但它也有代價：

高保真的東西，看起來太完成了。

當畫面已經有顏色、有圓角、有排好的卡片，討論很容易滑向：

「這個按鈕要不要再大一點？」

而不是：

「這個頁面到底該不該存在？」

所以如果重來一次，我會先問自己：

「這一步到底是要確認結構，還是確認互動？」

如果是要確認頁面有哪些、資訊怎麼排、RWD 基本方向怎麼處理，Wireframe 就很適合。

如果是要確認互動點下去順不順，那就需要 Prototype。

我們當時不是故意跳過 Wireframe，而是那時候根本不知道有這個選項，所以直接跳到了最高保真的互動空殼。

那份設計規範，後來真的變成約束了嗎

現在回頭看，答案是一半一半。

BuJo 的顏色、字體、陰影這些基本視覺設定，後來確實有寫進前端設定裡，變成可以重複使用的樣式基礎。

但共用元件和元件使用規則，不是一開始就完整建立好的。

所以專案裡還是有一些按鈕、彈窗和區塊，是各自按照當下需求長出來的。

這也是我後來才懂的：

設計規範如果只停在文件裡，它比較像參考；真的寫進樣式設定、元件庫和開發規則裡，才會變成約束。

這件事其實跟昨天講資料庫約束有一點像。

規則如果只寫在文件裡，就要期待每個人、每一次開發都記得遵守。

但如果它進到樣式設定、元件庫和開發流程裡，就會變成系統本身的一部分。

而且這種約束越早建立越有效。

太晚補上，就會變成前面已經長出一堆版本，後面才開始慢慢收編。

Vibe Coding：不要把「生出畫面」當成「完成設計」

那麼今天的主題——介面設計，在 Vibe Coding 和專業開發上的差異在哪呢？

想像一個情境。

你跟 AI 說：

「幫我做一個揪團排程網站的畫面。」

幾分鐘後，一個看起來相當完整的網站出現了：有導覽列、有卡片、有按鈕、有表單，配色也不難看。

真的會讓人很想直接說：

「哇，好像可以開始做功能了！」

但問題是，畫面長出來，不代表設計想清楚了。

Vibe Coding 很常漏掉的，不只是 RWD（Responsive Web Design，響應式網頁設計），還有元件拆分和共用元件規則。

AI 產出的第一版畫面，常常是在某一個預設桌機寬度下看起來很完整。

但如果沒有特別要求，也沒有實際檢查桌機、平板、手機等不同尺寸，它不一定會替你把響應式狀態都處理好。

元件也是一樣。

對還不熟程式開發的人來說，很容易只看到「畫面上有按鈕、有卡片、有彈窗」，卻不知道工程上還要思考：這些東西是不是應該拆成可重複使用的元件？不同頁面是不是該共用同一套規則？

如果沒有先定好設計規範和 Component Library，也沒有要求 AI 從既有元件裡拿東西，它很可能每次都生出一套「看起來差不多、實際上不一樣」的畫面。

一開始只是小地方不統一。

等專案變大，這些「差不多」就會慢慢變成維護成本。

到那個時候，想統一修改按鈕樣式、彈窗行為或卡片間距，就不再是改一個地方，而是要回頭整理散在各處的版本。

所以差異更像是：

• Vibe Coding：直接要最終畫面，風格層和結構層很容易跳過，也常常漏掉 RWD、元件拆分和共用元件規則，看起來最快
• 專業開發：一樣可以讓 AI 生畫面，但會先把風格、結構、流程、RWD、元件拆分和共用規則定下來，當成 AI 每次生成都要遵守的依據

AI 讓這三層每一層都變得更便宜了。

但它沒有讓任何一層變得可以完全省略。

畫面不是終點，而是團隊共識的起點

寫這篇以前，我其實一直把 Wireframe、Mockup、Prototype 這些詞，當成「設計師才會處理的東西」。

好像只要我們沒有設計師，又有 AI 可以幫忙生畫面，就很自然可以跳過它們。

但現在回頭看，我覺得介面規劃沒有固定答案。

一個人做，很多事情可以直接在腦中對齊。

但只要開始變成多人合作，就需要有一個大家都看得到、也能一起討論的共同版本。

真正重要的，不一定是每個團隊都要照著同一套流程，把所有傳統設計產物完整補齊。

真正重要的是，團隊有沒有在開始寫程式之前，用某種形式先回答幾個問題：

這個網站是做給誰用的？

User Flow 有沒有先跑過？

RWD 的方向有沒有先想過？

元件拆分和共用元件規則有沒有先定下來？

這些問題看起來都很細，但它們其實都在回答同一件事：

團隊是不是在做同一個產品。

BuJo 當時直接做出互動空殼，確實幫我們對齊了想像。

但如果能早一點知道 IA、User Flow、Wireframe、Mockup、Prototype 各自適合回答什麼問題，也能早一點把 RWD、元件拆分和共用元件規則放進討論裡，我們也許可以把一些會影響後續維護的問題，放在更便宜、更好修改的階段先處理掉。

所以我現在對介面設計的理解，不再只是「把畫面做漂亮」。

它更像是在開發前，先替使用者和團隊鋪一條比較清楚的路。

明天，我們要繼續看另一份很特別的文件：不是寫給使用者看的，也不是寫給工程師看的，而是寫給 AI 協作者看的專案規則——AGENTS.md／CLAUDE.md。

參考資料

• AI 產品設計工作流相關文章